What to Fix? Distinguishing between design and non-design rules in automated tools

Technical debt---design shortcuts taken to optimize for delivery speed---is a critical part of long-term software costs. Consequently, automatically detecting technical debt is a high priority for software practitioners. Software quality tool vendors have responded to this need by positioning their tools to detect and manage technical debt. While these tools bundle a number of rules, it is hard for users to understand which rules identify design issues, as opposed to syntactic quality. This is important, since previous studies have revealed the most significant technical debt is related to design issues. Other research has focused on comparing these tools on open source projects, but these comparisons have not looked at whether the rules were relevant to design. We conducted an empirical study using a structured categorization approach, and manually classify 466 software quality rules from three industry tools---CAST, SonarQube, and NDepend. We found that most of these rules were easily labeled as either not design (55%) or design (19%). The remainder (26%) resulted in disagreements among the labelers. Our results are a first step in formalizing a definition of a design rule, in order to support automatic detection.Comment: Long version of accepted short paper at International Conference on Software Architecture 2017 (Gothenburg, SE

What is Enterprise Technical Debt?

During architecture evaluations, we typically identify technical-debt issues within a single system or project. However, the impact of  technical debt often reaches beyond the scope of a single system or  project. In our work, we refer to this form of technical debt as enterprise technical debt.  Like all technical debt, enterprise technical debt consists of choices  expedient in the short term, but often problematic over the long term.  Ignoring enterprise technical debt can have significant consequences, so  architects should be alert for it, and they should not let it get  overlooked or ignored when they come across it. In this post, I provide  examples of enterprise technical debt (and the risk it represents) taken  from real-world projects. </p

A Closer Look at 804: A Summary of Considerations for DoD Program Managers

This report examines Section 804 National Defense Authorization Act (NDAA) for 2010 and related guidance documents through the lens of the Department of Defense (DoD) Information Technology (IT) Program Manager. The information in this report is intended to help the program manager reason about actions they may need to take to adapt and comply with the Section 804 NDAA for 2010 and associated guidance.</p

Challenges and Recommendations Gathered Through Interviews with Agile Program Managers and DoD Accreditation Reviewers

This material is based upon work funded and supported by the United States Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense. This report was prepared for the SEI Administrative Agen

DoD Information Assurance and Agile: Challenges and Recommendations Gathered Through Interviews with Agile Program Managers and DoD Accreditation Reviewers

funded research and development center. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense. This report was prepared for th

Towards better technical debt detection with NLP and machine learning methods

Abstract Technical debt (TD) is an economical term used to depict non-optimal choices made in the software development process. It occurs usually when developers take shortcuts instead of following agreed upon development practices, and unchecked growth of technical debt can start to incur negative effects for software development processes. Technical debt detection and management is mainly done manually, and this is both slow and costly way of detecting technical debt. Automatic detection would solve this issue, but even state-of-the-art tools of today do not accurately detect the appearance of technical debt. Therefore, increasing the accuracy of automatic classification is of high importance, so that we could eliminate significant portion from the costs relating to technical debt detection. This research aims to solve the problem in detection accuracy by bringing in together static code analysis and natural language processing. This combination of techniques will allow more accurate detection of technical debt, when compared to them being used separately from each other. Research also aims to discover themes and topics from written developer messages that can be linked to technical debt. These can help us to understand technical debt from developers’ viewpoint. Finally, we will build an open-source tool/plugin that can be used to accurately detect technical debt using both static analysis and natural language processing methods